back to DTinfo

What We Did to Port the Developer Toolbox to IRIX 6.2

and, What We Learned About In The Process

Chapter 1


This document is a record of everything we did to upgrade and then
re-compile the DT on IRIX 6.2 with the "bare-bones" o32 option.

Table of Contents
The reason this is "Chapter 1" is because we have not yet succeeded in
cleaning up DT source code so it is n32 capable. By so doing, one can
attain full access to 64-bit wide integer registers and 64-bit instructions
in a 32-bit address space. It is the janitor's understanding that achieving
such n32 "code robustness" is the developer's most basic and significant
undertaking in moving to IRIX 6.2 from an IRIX 5 universe. Some of the
relevant details about this are described in section 2, The Challenge of n32.







Upgrading the DT machine

The toolbox source, build, test and SGI-internal-website machine, named dtdustbin and aliased as "swank", is an IP19 6-processor Challenge-L system. In May, we upgraded swank from IRIX 5.3 to 6.2, changing the 2GB system disk to be an xfs filesystem in the process. Since the IP19 is 64-bit, we went thru the kernel upgrade from 32-bit without a hitch. We chose to switch our system to be xfs in anticipation of taking advantage in the future of creating a single LARGE "filesystem" by combining our series of 4-GIG disks to operate as a single partition. Prior to re-compiling the DT, we pass on a few tidbits of what we learned while upgrading swank.
  1. Choose "delay resolving conflicts" when inst'ing the "IRIX 6.2TM (Part 1 of 2)" CD
    documentation on this issue is not revealing itself so, from memory, this is the best that can be provided here: in upgrading to IRIX 6.2 with the two CDs labeled, "IRIX 6.2TM (Part 1 of 2)" and "IRIX 6.2TM (Part 2 of 2)", once you have made all the selections you want on the first (Part 1 of 2) CD, somewhere before or after typing "go" at the Inst> prompt, one is presented with two choices that say something like:

    1. resolve conflicts now
    2. delay resolving conflicts

    DON'T FALL INTO THE TRAP the silly janitor did of selecting number 1. never having seen this before, he was not aware of the fact that there would be a barrage of conflicts that would not be resolved since one needs to install BOTH Parts 1 AND 2 before outstanding conflicts are resolved. The alternative to selecting number 2 above is to turn the delay_conflicts Inst Preference to "on". Stepping into Inst and typing the command

      Inst> set delay_conflicts

    reveals such information as "Controls when certain "delayable" conflicts are presented to the user. . . . In some installation scenarios, the conflict will have to be delayed since the subsystem(s) necessary to resolve the conflict are not on the current distribution. . . . An `on' value will always present the delayable conflicts prior to exiting." This is precisely the case when the baseline eoe distribution spans 2 CDs as it does for IRIX 6.2. See "IRIX 6.2 Instructions for Customers Updating From Earlier IRIX Releases" (toolbox/documents/irix6.2/6.2errata.ps.Z), for more information.

    If for some reason you find yourself forced to take choice number 1, remember that all the defaults you had for any selected products that end up being removed are lost, so be sure to scan the choices carefully. In particular, do NOT do "keep N," or the system will be barely, or not at all, usable.

    For a listing of what products exist on the IRIX 6.2TM (Part 1 of 2) CD, see the section by the same name in the "IRIX 6.2 for System and Network Administrators" Pipeline article. Likewise for IRIX 6.2TM (Part 2 of 2).

  2. 6.2 depends on IL 2.5.1 -- DON'T attempt to load/use IL 3.0 on IRIX 6.2
    the janitor learned from one of the Image Library (IL) gauds in engineering that IRIX 6.2 depends on IL 2.5.1. he had mistakenly updated to IL 3.0 since that version was what existed in the 6.2/all directory of inst images on the SGI internal dist machine. with IL 3.0, applications like toolbox/src/ibrowse and toolbox/src/exampleCode/movies/cineswipe/libcineswipe failed to compile, producing Errors of the kind,

      #error     This header file is obsolete, use <ifl/iflSize.h> or define IL2_5_COMPAT

    -- but even defining IL2_5_COMPAT in the Makefile did not resolve the errors. that's when we learned that 3.0 is not the IL meant to be used with IRIX 6.2. we got back on track by doing a

      versions remove il_eoe il_dev

    as root, and then installing the 2.5.1 version. after this, everything once again worked without any barking from the compiler.

  3. one only needs 4 subsystems from the 2.0.1 performer_dev.sw image
    the janitor learned from one of the Performer gauds in engineering that of the performer_dev.sw image, the only subsystems needed to do basic compilations of performer code are:
    1. performer_dev.sw.hdr
    2. performer_dev.sw.common_performer
    3. performer_dev.sw.ogl_performer
    4. performer_dev.sw.igl_performer



The Challenge of n32

Prior to creating the necessary porting environment by explicitly specifying the /usr/lib32 n32 library location (see N32 Porting Guidelines from the MIPSpro(TM) N32 ABI Handbook), the janitor faces the fact that a great deal of code currently resident on the DT needs loads of ANSI "polish" applied to it before it is ready for the successful jump to n32.

We did perform one "trial pass" of the toolbox/src subtree with -n32 activated. To do this we conferred with the make/commondefs/commonrules gaud in engineering who explained how to modify the IRIX 6.2 version of the /usr/include/make/releasedefs file (installed from the eoe.hdr.lib subsystem) so that instead of definining

we switched these to be By doing this, we witnessed the IRIX 6.2 o32 "default compiler settings" -- using -mips2 -o32 compile lines of the form,

//usr/bin/cc -fullwarn -I..//include -c -nostdinc -I//usr/include -mips2 -o32 -O -MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499 -c axes.c

-- change to employ the -mips3 -n32 flag:

//usr/bin/cc -fullwarn -I..//include -c -nostdinc -I//usr/include -mips3 -n32 -O -MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499 -c axes.c

The results of this trial pass (running make -i >& makeLog to continue compilation past fatal errors) produced many errors which, under the o32 libraries did not even show up as warnings. One way of measuring the differing results of o32 and n32 in the toolbox/src subtree is that the files generated by redirecting STDOUT/STDERR were orders of magnitude different in size:

From this, we are looking at pursuing two parallel tracks in order to start providing n32-compiled binaries-from-DT-source come this fall:

  1. Begin polishing selected programs in the current DT tree
  2. Begin integrating new content that already compiles cleanly using n32

From 1 above, the requisite "polish" to create n32-compilable source will include such areas of attention as

  1. resolving all errors produced by -fullwarn option of the kind

  2. using function prototypes where they currently aren't being defined.
    It is critically important to be aware of this: some programs won't work correctly -- even if they compile -- if they don't have the prototypes in force, particular for varargs and math routines, but not restricted to those. Quoting from a relevant segment of the Native 64-Bit (N64) and N32 Subprogram Interface for MIPS Architectures section of Chapter 2: Calling Convention Implementations of the the MIPSpro(TM) N32 ABI Handbook:

  3. as time permits, resolving the massive amount of warning messages.
    Some of these warnings are due to SGI's header files (particularly those from the X and motif consortiums) not being truly ANSI-clean. Disabling those warnings with -woff gets rid of much of the "noise" at the cost of perhaps missing some potential problems in your own code. The janitor hopes you understand and appreciate the value and benefit running "make -i" is providing us in the errors the new compilers found in the DT code and that the "noise" produced is justified in that it finds real problems.

    Also recommended is employment of the compiler option -diag_error -- "The messages with the specified numbers are treated as errors. In particular, if any such message is reported, no object file will be generated" -- which can make specific warnings fatal, to ensure you don't get sloppy once you have clean things up (engineering groups inside SGI have done this on the kernel, and some other parts of the system). The process of cleaning up one's code often does find real and sometimes longstanding bugs.

Obviously number 3 is a laudable goal, but in the actual, pragmatic world, will get short shrift with the passage of time. To compensate for this, we are also honing our information ferreting teeth for this fall, so that once we have completed spinning the v6.1 DT, we can actively begin to identify, locate, qualify, and integrate source that passes the "n32 compatibility test" with flying colors. After the release of v6.1 we will begin creation and population of an "N32-compliant apps on the DT" web page (initially it will show up in the NEW page, and, i'm sure, end up on the HOT page as well as in all the appropriate global (topical, A-Z Documents) file listings).

As an aside, for those who would like to know what commands are n32 on IRIX 6.2, look for the following output from file(1):

Other "n32 graduates" include: csh, ksh, and rqs32.




o32 and n32 Pointers

To be precise: Our Goal in all this is the following:

If you support R4000 platforms on IRIX 6.X, you will want to compile This gives you the compiler improvements of newer compiler optimization technology without converting your pointers to 64-bit.

If you are supporting mips4 platforms and want to tune for those systems, then compile

(if you have checked your code for 64-bitness add -64). This will limit the systems that can run -mips4 (R4000 is mips3) but should give your code a boost.
For some of the salient information on the o32 and n32 ABI implementations in IRIX 6.2, see





What DT Source Code Changed



MAJOR UPGRADES:




MINOR UPGRADES:

#include <sys/IP5.h> #include <sys/clover2.h> 
cfe: Error: cdtodat.c, line 589: The number of arguments doesn't agree with the
number in the declaration.
     if (argc == 2 && !strncmp(argv[1],"-q")) {
 -----------------------------^

ld: ERROR 33: Unresolved text symbol "endqstrip" -- 1st referenced by //usr/lib/libsphere.a(sphere.o).
int sginap(long); 
redeclaration of 'sginap'; previous declaration at line 427 in file '//usr/include/unistd.h'

signal(SIGINT, terminate_server);       // let user kill server
signal(SIGTERM, terminate_server);      // let user kill server

signal(SIGINT, (SIG_PF)terminate_server);       // let user kill server
signal(SIGTERM, (SIG_PF)terminate_server);      // let user kill server

 
#ifndef __sigret_t
#define __sigret_t      void
#endif
typedef __sigret_t      (*SIG_PF) (__sigargs);

AFgetsampfmt(f, AF_DEFAULT_TRACK, &fmt, &width)


  • toolbox/src/exampleCode/i18n/

  • toolbox/src/exampleCode/inventor/noodle/ 
    #include "<Inventor/fields/SoMFInt32.h>"
    #include <errno.h> 
    controls->outType = outputInfo[0].type;
strcpy(controls->movieParms.compType, outputInfo[0].comptype);
controls->movieParms.mvFileFormat = outputInfo[0].filetype;
    #include <time.h> 
    ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o).

    ld: ERROR 33: Unresolved text symbol "XtWidgetToApplicationContext" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o).

    ld: ERROR 33: Unresolved text symbol "XCreateColormap" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o).

    ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by /usr/lib/libGLw.a(GLwMDrawA.o).

    ld: ERROR 33: Unresolved text symbol "translate" -- 1st referenced by //usr/lib/libsphere.a(sphere.o).

    ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o).

    cfe: Error: //usr/include/stdlib.h, line 235: Syntax Error
 extern void swab(const void *, void *, ssize_t);
 ---------------------------------------^

    ld: ERROR 33: Unresolved text symbol "XOpenDisplay" -- 1st referenced by util.o.
    #include <errno.h> 
    "fancyText3.c++", line 83: error(3346): function
	  "SoMFInt32::setValues(int, int, const long *)" is inaccessible
        lp->index.setValues(0, 4, index);

    DELETED:

    INCLUDED BUT NOT PORTED TO IRIX 6.2:

    (we still include the src for people on IRIX 5, as well as the possibility of more collaboration between the janitor and all of you [4].) 

    cfe: Error: //usr/include/sys/sbd.h, line 80: Syntax Error
 <<BOMB -- need define for unanticipated page size >>

    % setenv LD_LIBRARY_PATH .
% ivview -q test.iv
Inventor read error: Unknown class "RevoSurfEngine"
        Occurred at line  74 in ./test.iv

    ld: ERROR 33: Unresolved data symbol "glBindTexture" -- 1st referenced by /usr/lib/libfGL.a(libfogl32.o).


    NOTES:

    1. While the math library used to be automatically included whenever -lgl or -lX11 was invoked, that is no longer the case in irix 6.2. Now -lm must be explicitly included wherever math functions are employed.

    2. The explicit use of libmalloc rather than the malloc inside libc now produces rafts of errors of the order: 
    ld: WARNING 85: definition of realloc in //lib/libmalloc.so preempts that definition in //usr/lib/libc.so.
      A question the janitor had was, and answers included,

    1. In order for all Image Library programs on the toolbox to successfully compile on IRIX 6.2, one MUST BE SURE one is using the 2.5.1 version of the il_eoe and il_dev products. Attempting to use the 3.0 versions of the Image Libraries will not work as the janitor discovered. 2.5.1 is THE version of the IL that is compatible with and intended for irix 6.2.

    2. Pursuing our goal of extending collaboration between the DTjanitor and everyone in the Developer Program, while we were not able to port/successfully recompile these programs to/on IRIX 6.2, we nevertheless include their source so that, if anyone of you has the saavy, and finds the inclination/motivation enabling you to succeed in reviving these programs, PLEEZE send us whatever files (source, Makefile, etc.) you modify to "make it go" again, and we will add these back into the v6.2 DT release as working-again src+binaries.

    3. Artifact of the "one-pass linker" produces errors of the form:
        ld: ERROR 33: Unresolved text symbol .....
      using the example of src/exampleCode/audio/sonic/ above,
        since libsphere makes function calls which are resolved by libgl, you need to switch the order of those two libs on the link line. This is an artifact of the "one-pass linker": since the symbols are 1st referenced by libsphere, they were not resolved when the linker processed libgl, where the symbols are defined but not referenced.




    _________________________
    References

    1. MIPSpro(TM) N32 ABI Handbook, Chapter 2: Calling Convention Implementations

    2. Ibid, Chapter 4: N32 Examples and Case Studies

    3. Ibid, Chapter 3: N32 Compatibility, Porting, and Assembly Language Programming Issues

    4. Ibid, Contents of This Guide